The present invention relates to software architecture and a method for creating and developing software for reuse.
The development of large-scale business applications has always been a problematic task. The steps of gathering requirements, designing the application, selecting the appropriate technology, testing the implementation, and deploying the resulting product is typically done in isolation and without an awareness of other applications that already exist or are being developed simultaneously.
When software applications are developed within a business enterprise in this manner many of the same business and technical problems are being addressed and solved by separate and distinct software applications. Typically, the software applications are created by different programming groups within the business enterprise which results in applications having different designs and different technologies, thus, sharply diminishing the possibility of code reuse. Moreover, development times are lengthened since generally each programming group solves similar sets of problems for each application being developed.
A further complication that arises from developing applications in this xe2x80x9cstove pipe xe2x80x9d fashion is that the operating environment for the applications becomes cluttered with many different brands of technology resulting in increased operational complexity. An ineffective utilization of computer resources also results.
One technology which has been developed to combat the problem of code reuse is object-oriented programming. The advent of object-oriented programming technologies such as C++ and Java allows for constructing objects that may, in theory, be reused from one application to another. Reuse is one of the highly advertised advantages of these programming technologies, but there are some shortcomings. Languages such as C++ and Java allow programmers to construct software objects, however they do not prescribe how such objects should be built so that another program can easily reuse them. For example, if a programmer designs a business object that can process credit card transactions and the object provides a graphical user interface for inputting the transactions, typically the graphical user interface cannot be easily separated from the object. Consequently, another programmer wishing to the use the object, but without the graphical user interface, would need to re-design the object.
Another limitation of today""s object-oriented programming technologies is that they do not directly support dynamically-shared object reuse. For instance, if a programmer wants to reuse a C++ object, the programmer must include the object definition in the new program, create an instance of the object, and manage the object as part of the new program. The instantiated object that exists in the original program is not accessible to the new program, thus, a copy of the object must be created inside the new program. Although this technique results in some code reuse it does not result in true object or program sharing. The definitions of the objects are shared, but not the objects themselves.
Therefore, it is an object of the present invention to provide a system and method for building large-scale business applications having reusable software programs Known as services.
Accordingly, the present invention provides a system and a method for developing software applications for reuse. The instant invention defines first, a service which is a well-known, dynamically callable software program that is currently in existence and is running somewhere in the business concern or enterprise on a computer network.
A service has a well-known name and a well-defined interface that clearly and precisely defines the service""s inputs and outputs. In order for the service to be well-known, the service name, the interface definition, and location where the service runs, are published in a services directory. If another service or program wants to use this service, it may look up the information needed to call the service in the services directory. Having this information about the service registered and available for use by other services or programs means that the service is location-transparent.
The service is available to any program that has a need for the outputs provided by the service through an established and agreed-upon network protocol. Having a consistent network communication protocol across the population of all services provides a quality called ubiquitous service connectivity, meaning that any service or program can call on the functions of any other service, using the established network communication protocol.
The service runs independently of the calling program, and does not require the calling program to implement or import any of the service implementation code. Having the services run independently of each other means that the services are implementation-transparent. Thus, the instant invention provides true sharing of running programs by the applications that need the functions provided by those services. Additionally, the instant invention provides a framework for organizing a plurality of service programs. This framework is called logical layering. Logical layering provides a structure whereby a service can be developed at the right level of complexity and functionality so as to allow future programs to call the service without requiring the redundant and wasteful task of redesigning the service.
The services-based method prescribes that each new application is designed out of a cooperating set of services. The present invention requires that software developers discover what services are currently available, and which of these services may be reused. Moreover, a developer must also understand which services must be implemented for the first time and at which logical level they are needed. Over time, the present invention provides the business enterprise with a set of re-useable services which will make it easier and faster to build each new enterprise application.